When introducing the Bus/Device split in #351, I kept the ability to represent "read-only" and "write-only" buses, with separate SpiBusRead, SpiBusWrite buses. This didn't have much discussion, as it was the logical consequence of keeping the separation in the already existing traits (Read, Write, Transfer, ...).

Later, in #443, when switching from the closure-based API to the operation-slice-based API, this required adding SpiDeviceRead, SpiDeviceWrite as well, because you can no longer put a bound on the underlying bus with the new API.

This means we now have seven traits, which we can reduce to two if we drop the distinction. So, is the distinction worth it?

I've always been on the fence about it, now I'm sort of leaning towards no.

First, using write-only or read-only SPI is rare.

• write-only SPI: for SPI displays you don't want to read from, or to abuse it to bitbang stuff like ws2812b,
• read-only SPI: some ADCs that can't be configured at all, you just clock out bits. Or even weirder abuses, like to build a logic analyzer

Second, for it to be useful HALs have to track "read-onlyness / write-onlyness" in the type signature, so a read-only SPI really only implements SpiBusRead and not SpiBus. HALs already have enough generics. For example, Embassy HALs don't implement the distinction (you can create MOSI-only or MISO-only SPIs, but they all impl the full SpiBus, because I didn't want to make the types carry pin information).

Third, it makes the API easier to use. Simpler, users only have to import one trait, docs have all the methods in one place. Much less boilerplate to impl the traits (look at how shorter embedded-hal-bus gets!).

So I think we should remove them.